Skip to main content
Version: 2.0

Business Models

For engineering leaders, “business model” often feels like a term tossed around by the suits upstairs. Something to support, but rarely to deeply understand. We get tasked with building features for a “platform” or a “subscription service” without truly grasping why that model was chosen, or how our work directly impacts its success. This disconnect is a huge missed opportunity. Understanding the business model isn’t just about being a team player; it's about making better engineering decisions, prioritizing effectively, and ultimately, building products people need.

I recently worked with a team building a new mobile app. They were incredibly focused on implementing the latest AI-powered features, believing it would set them apart. However, the core business model relied on high-volume, low-cost transactions. The AI features, while technically impressive, added significant complexity and cost, ultimately hindering their ability to achieve profitability. This misalignment highlighted a critical truth: technical brilliance must be grounded in a viable business foundation.

Over two decades in this field, I've seen brilliant engineering efforts flounder because they weren’t aligned with a viable business model. Conversely, I've seen simpler solutions thrive because they perfectly fit how the company intended to make money. Let’s move beyond the buzzword and explore how to build business models that actually work, from an engineering leadership perspective.

The Core of a Business Model: More Than Just Revenue Streams​

Too often, we equate a business model with simply “how we make money.” It’s far more nuanced. Think of it as a system – a set of interconnected elements describing how a company creates, delivers, and captures value. A solid framework to break it down? The Business Model Canvas.

While the Canvas is excellent for understanding the current state, as engineering leaders, we need to be particularly attuned to how changes to the model will impact our work. Here's how I think about it in practical terms:

  • Value Proposition & Customer Segments: Who are we really solving a problem for? And what problem are we solving? This isn't a marketing exercise – it’s foundational to technical choices. Are we building for a mass market (think simplicity, scalability)? Or a niche audience requiring specialized features and high performance?
  • Revenue Streams & Cost Structure: How exactly does this translate to revenue? Subscription? Transaction fees? Advertising? Understanding this dictates how we measure success, prioritize features (e.g., focus on features that drive renewals vs. those that drive initial sign-ups), and even architect our systems. For example, a transaction-based model demands robust transaction processing and auditability, while a subscription model prioritizes customer retention and personalization. A freemium model, for instance, requires robust usage tracking and tiered access control in the codebase.
  • Key Activities & Resources: What are the core things the company must do well to make the model work? This dictates what technical capabilities we need to build and maintain in-house, versus what we can outsource or leverage through third-party services.

The Peril of Feature Creep & The Power of First Principles​

One of the biggest pitfalls I've seen? Chasing after the “next big thing” without a solid understanding of whether it aligns with the underlying business model. A classic example? Investing heavily in AI features for a product whose core value proposition is simplicity and affordability.

As Peter Thiel points out, successful people “think about business from first principles instead of formulas.” What does that mean for us? Don’t just copy what competitors are doing. Deconstruct the business model. Understand the fundamental drivers of value. Ask “why” repeatedly until you get to the core assumptions.

For example, before committing to a new feature, I always ask my team:

  • “How does this directly contribute to our revenue?”
  • “What customer segment will benefit most from this?”
  • “What are the key metrics that will tell us if this is successful?”
  • “What are the costs of building and maintaining this feature over the lifecycle of the feature?”

These questions force us to think critically about the business model and ensure that our efforts are aligned with the company’s goals.

The Engineering Leader’s Role: A Bridge Between Technical Vision & Business Reality​

Ultimately, engineering leaders aren't just responsible for building great products; we’re responsible for ensuring that those products are viable businesses. This necessitates:

  • Active Participation in Strategic Discussions: Don’t wait to be told what to build. Proactively participate in discussions about the business model and challenge assumptions.
  • Data-Driven Decision Making: Use data to validate (or invalidate) assumptions about the business model. Track key metrics and share insights with the broader team.
  • Clear Communication: Translate complex technical concepts into business terms and vice versa. Help the team understand why we’re building what we’re building.

I've seen countless instances where a simple, well-understood business model, executed flawlessly, has outperformed a technically brilliant but poorly conceived one. As engineering leaders, we have a crucial role to play in ensuring that our technical prowess is aligned with a viable, sustainable business model. It’s not enough to just build it; we need to understand why we’re building it, and how it will drive value for the company and its customers.

In the future, successful engineering leaders will be those who can not only build great products but also proactively shape the business models that support them.